App安全测试

APP安全威胁

在App项目中都会碰到三座App安全大山。App客户端安全、数据传输安全、App服务端安全。下面以分析检测的思路进行对App安全威胁的这三座大山进行一些剖析梳理总结。

工具介绍

静态分析工具 : Apktool、dex2jar、jadx-gui、JEB、Androidkiller、GDA。

动态分析工具 : DDMS、gdb、IDA、Drozer。

抓包分析工具 : Fiddler、Wireshark、charles。

挂钩框架 : frida、xposed。

其他工具 : JDK、AndroidSDK、AndroidResEdit、uiautomatorviewer、010 editor、jarsigner。

App客户端安全测试

运行环境检测

    1.反编译App代码，查看App中是否存在检测root的关键代码。

    2.运行App程序，观察确认是否能够正常运行并有对应提示用户信息。

通过上图静态分析App的java实现代码，可以很清晰的看到代码中有实现对root检测，通过检测可以改root的关键App包和检测root后的特有关键路径方式进行判断环境信息。

反编译检测

1.可以利用apktool、de2jar、jadx-gui工具，进行反编译查看分析代码。

2.直接利用可视化工具AndroidKiller、GDA、JEB工具进行反编译分析代码。

下面以apktool反编译方式进行对反编译dex分析。

（对于App中so文件，可以直接用IDA工具进行静态反编译分析arm汇编代码）

App实际上是一个zip压缩包格式，可以直接将后缀修改成zip后缀，进行解压就可以获取到App的包数据。

通过利用dex2jar命令行将dex文件转换为jar（java代码）文件。

命令格式:dex2jar.bat  要转换的dex文件路径

通过jadx-gui工具，进行查看分析jar文件的java代码。

经过这个App反编译dex流程分析:上图的App虽然可以通过反编译工具进行反编译，但是该App采用了360加固保护，dex文件里面的数据都是360加固的数据，真正的dex数据都被隐藏和抽取了。所以该App的反编译这项是相对安全的。

客户端完整性检测

在App中的每个文件都会做一次算法记录，并保存在MANIFEST.MF文件中，我们就可以通过基于MANIFEST.MF文件的安全机制对App包进行完整性校验检测。完整性校验可以在启动App时候触发，如果App被二次打包修改了，那么MANIFEST.MF文件中的校验信息是不一样的。

1.通过利用AndroidKiller工具对App进行反编译，修改，二次打包并签名。

2.通过apktool进行反编译、修改、打包，再通过SignApk工具进行对App重新签名。

下面以androidkiller工具进行App替换图片的完整性检测分析。

将App直接拖入androidkiller工具里面，在工具的工程管理界面下res是App所有资源图片所存放的位置。只要右击res文件夹进行打开文件路径，就可以跳转到App反编译后的资源文件夹。

可以通过提取其他App的资源图片进行替换，替换完图片后将App重新编译并签名。

通过分析:如果App没有完整性校验的功能，那么App就可以通过反编译修改，二次打包签名并能正常运行。如果App有完整性校验功能，那么App二次打包后，是不能正常运行的。

安全App的做法是：在每次启动App的时候，进行对自身App完整性校验，并且在验证App逻辑中，不要单纯的只使用MANIFEST.MF文件中的数据为验证条件，最好同时验证是否有不属于App的文件，这个过程可以和服务端进行结合完成。

组件安全检测

Android四大组件简介

Activity：呈现可供用户交互的界面，是最常见的组件；

Service：长时间执行后台作业，常见于监控类应用；

Content Provider：在多个APP间共享数据，比如通讯录；

Broadcast Receiver：注册特定事件，并在其发生时被激活。

Android的四大基本组件，都需要注册才能使用。每个Activity、service、Content Provider都需要在AndroidManifest文件中进行配置。AndroidManifest文件中未进行声明的activity、service以及Content Provider将不为系统所见，因此这些组件就不可用。而broadcast  receiver广播接收者的注册分静态注册（在AndroidManifest文件中进行配置）和通过代码动态创建并以调用Context.registerReceiver()的方式注册至系统。需要注意的是在AndroidManifest文件中进行配置的广播接收者会随系统的启动而一直处于活跃状态，只要接收到感兴趣的广播就会触发(即使程序未运行)。

对于android的组件安全性的问题，主要在于关注组件是否被外部App应用给调用。

1.通过分析App中的AndroidManifest.xml文件，判断组件属性是否设置为导出状态。设置导出状态外部的App就可以直接调用。

2.通过利用drozer工具进行分析验证组件是否存在安全性问题。

下面以AndroidManifest.xml文件的android:exported属性进行判断组件安全性。

从上图中可以看到activity组件android:exported设置为true，并且有intent-filter属性，这个activity表示就可以直接被外部App应用调用。

检测分析得出结论：android的组件如果设置为导出状态，那么组件就有被直接调用或被劫持的风险。建议如果组件非必要导出情况下，将组件设置为不导出状态，如果组件必须提供给外部应用进行调用的话，建议对组件进行权限控制。

调试信息检测

检测App应用程序（保护服务端应用）调试信息是否关闭，调试信息中是否写入敏感信息。

通过运行App程序，查看logcat等调试日志信息方式，分析是否有泄漏重要的URL地址、提示信息、调试信息等敏感关键字以及程序逻辑的关键流程信息。

通过利用DDMS工具进行查看App运行过程中是否有调试日志信息。

通过DDMS中LogCat窗口，进行右击打开过滤窗口，可以选择针对只显示指定进程或Pid的数据，这样就可以进行精准查看分析App中是否有敏感日志信息输出。

键盘输入安全性检测

在App应用中，默认情况下使用系统自带的软键盘，在App安装后，如果直接使用系统自带键盘，会有被记录、劫持的风险。我们可以通过在App应用输入信息的时候，观察是否会弹出自定义的软键盘。安全的做法通过实现自定义的软键盘并且键盘码会进行变动。

以下对键盘应用进行做定义分析

1、APP输入调用安卓系统键盘

一般认为高风险，可能被劫持利用。

2、APP调用应用中自带键盘输入

一般认为中风险，可能被其他APP以触摸点绝对定位方式劫持。

3、APP调用应用中自带键盘并随机打乱键盘顺序 （这种设置一般银行APP比较多 有 打乱数字和键盘按键的 还有在这个界面下禁止截图的）

一般认为低风险，就算被劫持，利用可能性也很低。

本地数据安全检测

App本地数据安全性问题需要关注的问题分别为:App所在目录的文件权限、SQLite数据库文件的安全性、敏感数据明文直接存储Sdcard。

对于App所在目录的文件权限问题，通过验证App所在目录的文件权限是否进行设置，如果是非root用户是否可以进行读写执行App目录下的文件。安全的情况下App所在的目录，其他用户必须无法进行读写操作。

对于SQLite数据库文件问题，SQLite是一个轻型的数据库文件，它是很多App都是使用的一种数据存储方式，其中微信就是利用SQLite文件方式进行存储数据。可以通过SQLiteSpy和其他第三方工具，进行打开查看SQLite文件的数据。主要需要关注下db文件是否直接存储敏感信息，是否对db文件有做加密处理。

对于敏感数据是否存储在Sdcard上，可以通过运行App应用，然后进行查看是否有在“sdcard/Android/data/包名/” 目录下，释放一些敏感文件或敏感的数据。

安全做法是对于释放在sdcard目录上的数据和文件都应该做加密处理。

数据传输安全

App中的通信数据传输主要可以借助第三方抓包工具，采取代理方式进行对HTTP、HTTPS数据包抓取和分析。验证App的通讯方式是否采用HTTPS加密信道，通过抓取App数据包确认是否进行加密以及是否进行证书校验。安全的做法是通过代理抓App数据是抓取不到，或者检测有用户抓取App数据时候进行强制退出。

下面以charles工具设置代理方式进行抓包。

电脑主机上设置要代理端口。

手机环境下设置电脑主机的IP地址和charles电脑端设置的相同端口。

这样就可以进行对手机环境下的App应用进行数据抓包分析了（具体包分析过程，具体需求具体分析）。

App服务器安全

App服务端安全需要关注的是服务端API安全、业务逻辑安全、中间件安全、服务器应用安全。主要可以通过渗透测试的方式对App的服务器进行安全检测，通过模拟恶意攻击方式进行对服务器攻击。从而提高App服务器的安全性。

E N D

                ▲往期相关文章▼

点个赞和

在看

你最好看